<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<HTML>
<HEAD>

<TITLE>
SAP Java Connector 3.0 Release notes
</TITLE>

<LINK REL ="stylesheet" TYPE="text/css" HREF="./sap.css" TITLE="Style">

<SCRIPT type="text/javascript">
function windowTitle()
{
    parent.document.title="SAP Java Connector 3.0 Release Notes";
}
</SCRIPT>
<NOSCRIPT>
</NOSCRIPT>

</HEAD>

<BODY BGCOLOR="white" onload="windowTitle();">


<!-- ========= START OF TOP NAVBAR ======= -->
<A NAME="navbar_top"><!-- --></A>
<A HREF="#skip-navbar_top" title="Skip navigation links"></A>
<TABLE BORDER="0" WIDTH="800" CELLPADDING="1" CELLSPACING="0" SUMMARY="">
<TR>
<TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1">
<A NAME="navbar_top_firstrow"><!-- --></A>
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3" SUMMARY="">
  <TR ALIGN="center" VALIGN="top">
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="intro.html"><FONT CLASS="NavBarFont1"><B>Home</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="installation.html"><FONT CLASS="NavBarFont1"><B>Installation</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="useful.html"><FONT CLASS="NavBarFont1"><B>Configuration</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="index.html" target="_blank"><FONT CLASS="NavBarFont1"><B>API Documentation</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="examples.html"><FONT CLASS="NavBarFont1"><B>Examples</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1Rev">    &nbsp;<FONT CLASS="NavBarFont1Rev"><B>Release Notes</B></FONT>&nbsp;</TD>
  </TR>
</TABLE>
</TD>
</TR>

<TR>
<TD COLSPAN=2 BGCOLOR="white" CLASS="NavBarCell2">&nbsp;</TD>
</TR>

<TR><TD>
<HR>
<CENTER>
<H1>SAP Java Connector 3.0</H1>
</CENTER>
</TD>
</TR>

<tr><td>&nbsp;</td></tr>
<tr><td><FONT SIZE="+1"><B>Release notes 3.0.9</B></FONT></td></tr>
<tr><td>&nbsp;</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix removing a memory leak in the JCoTimeoutChecker thread</b></td></tr>
<tr><td>
A memory leak was removed at the internal destination management within the <code>JCoTimeoutChecker</code> thread. This memory
leak was created each time that the registered <code>DestinationDataProvider</code> instance updated or deleted a previously
used destination from its destination configuration repository.<br>
<em>Note:</em> This bug was present in JCo release 3.0.8 only.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for CPIC communication error "client with wrong appc header version rejected"</b></td></tr>
<tr><td>
A program error in the underlying native CPIC communication software layer has been fixed that sometimes led to RFC connections
getting broken. In this case a <code>JCoException</code> with error group <code>JCoException.JCO_ERROR_COMMUNICATION</code>
was thrown and contained the CPIC error message "client with wrong appc header version rejected". Please see SAP note
<a href="https://service.sap.com/sap/support/notes/1664732">1664732</a> for further information.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for RFC callback handling</b></td></tr>
<tr><td>
RFC callbacks to the JCo framework were not handled correctly. Although receiving an RFC callback is not an error by itself,
there was always an error of type <code>RfcGetException</code> with message "Received a callback from the communication partner"
logged in the RFC error log file <code>dev_jco_rfc.trc</code>. Despite this log entry, no error or exception was thrown to
the JCo application or signalled to the communication partner. Even if the requested RFC function module was not available
and could not be processed, this was not done and the RFC callback was ignored. If the delta management for RFC table parameters
was active, the erroneous RFC callback handling could furthermore have caused lost table data and table data inconsistencies
between the two communication partners.<br>
Now RFC callbacks are handled correctly with throwing a <code>JCoException</code> of error group
<code>JCoException.JCO_ERROR_SYSTEM_FAILURE</code>, if the requested function module is not available, and only in this case
an error is logged to the RFC error log file <code>dev_jco_rfc.trc</code>.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for the middleware property 'jrfc.client_connect_timeout' having no effect</b></td></tr>
<tr><td>
RFC logon attempts to an SAP ABAP system have not been interrupted if they were running too long and exceeded the time span
that was specified by the JCo middleware property <code>jrfc.client_connect_timeout</code> (default is 60 seconds). Now a
<code>JCoException</code> with error group <code>JCoException.JCO_ERROR_TIMEOUT</code> will correctly be thrown in such a
situation, thus interrupting the currently running RFC logon attempt.<br>
<em>Note:</em> This bug was present from JCo release 3.0.5 to 3.0.8 only.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for setting the default or an empty value into fields of type XSTRING</b></td></tr>
<tr><td>
After calling method <code>JCoRecord.setValue([name|index], null)</code> or
<code>JCoRecord.setValue([name|index], new byte[0])</code> for setting the default or an empty field value on fields of
type <code>JCoMetaData.TYPE_XSTRING</code>, the field was not cleared and empty afterwards but contained one 0-byte value,
i.e. a byte array of length 1 (<code>byte[] = { 0x00 }</code>). This 0-byte value was also sent via RFC to the
communication partner, if the <code>JCoMetaData.TYPE_XSTRING</code> field was part of an importing, changing or tables
parameter in a <code>JCoFunction</code> or a <code>JCoRequest</code> object.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for writing JCo traces when using a JCoServerRequestHandler</b></td></tr>
<tr><td>
When using the RFC request/response model at the <code>JCoServer</code> side with a <code>JCoServerRequestHandler</code>
instance processing the incoming RFC requests, JCo neither traced the API calls to the <code>handleRequest(...)</code>
method invocations nor any meta data or content data of these RFC requests, even if the respective JCo trace level was
set for writing such information.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Improved JCo initialization for recognizing additional Java system properties</b></td></tr>
<tr><td>
In addition to setting the properties <code>jco.session_timeout</code> and <code>jco.session_timeout.check_interval</code>
with the method <code>JCo.setProperty(String key, String value)</code>, these two properties can now also be set as Java
system properties with the <code>-D</code> argument when starting the JVM and they will be recognized at JCo initialization.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Support of user/password logon while using SNC</b></td></tr>
<tr><td>
With the new destination logon property <code>jco.client.snc_sso</code> it is possible to turn off the Single Sign On (SSO)
mechanism of SNC by setting it to the value <code>0</code>. Thus, it is possible to log on to an SAP ABAP backend system
with some other user ID not fitting to the SNC identity, while SNC can still be used for encrypting the network
communication. As a prerequisite, a minimum SAP system kernel patch level is required as mentioned in SAP note
<a href="https://service.sap.com/sap/support/notes/1701870">1701870</a>.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Support of logon with external user identification data</b></td></tr>
<tr><td>
The destination properties <code>jco.client.extid_type</code> and <code>jco.client.extid_data</code> have been added
for supporting to log on with external user identifaction data to an SAP ABAP backend system. For this logon variant it is
mandatory to use SNC.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Improved logon procedure for languages available in Unicode SAP systems only</b></td></tr>
<tr><td>
Some languages like Armenian, Georgian, Vietnamese, Macedonian and many others are available in Unicode SAP systems only.
If logging on with such a language to an SAP ABAP backend system, it was mandatory to specify an additional destination
property like <code>jco.client.codepage</code> with indicating a unicode communication type, otherwise such logons failed
with an <code>JCoException.JCO_ERROR_LOGON_FAILURE</code> showing the error message "Select one of the installed languages"
although the appropriate language was installed.<br>
This logon procedure has been improved so that it does not require any additional communication code page destination
property anymore in this case. The unicode communication type is now automatically detected and used for logging on with
such new SAP system language keys.<br>
Please see SAP note <a href="https://service.sap.com/sap/support/notes/895560">895560</a> for more details on languages
that are only available in Unicode SAP systems.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>New APIs</b></td></tr>
<tr><td>
The following new APIs have been added and are available for general use:
<code>
<ul>
    <li>JCoDestination.getSncSSO()
    <li>JCoDestination.getExternalIDData()
    <li>JCoDestination.getExternalIDType()
    <li>JCoCustomDestination.SncConfigurationData.setSncWithSSO(boolean)
    <li>JCoCustomDestination.UserData.setExternalIDData(String)
    <li>JCoCustomDestination.UserData.setExternalIDType(String)
    <li>JCoDestinationMonitor.getWaitingThreadCount()
</ul>
</code>
See the API Documentation for details.
</td></tr>

<tr><td>&nbsp;</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td><FONT SIZE="+1"><B>Release notes 3.0.8</B></FONT></td></tr>
<tr><td>&nbsp;</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix removing a memory leak in JCo native JNI layer</b></td></tr>
<tr><td>
A memory leak in the native layer existed when receiving data from the backend. Thus, more and more
native memory was allocated and the process could run out of memory. Please check
SAP note <a href="https://service.sap.com/sap/support/notes/1595477">1595477</a> for details.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix removing a memory leak in JCoRepository</b></td></tr>
<tr><td>
Under certain circumstances, a memory leak was caused by the internal destination management within a repository. This
could have happened when creating many <code>JCoCustomDestination</code> instances from destinations, which did not
have an associated repository yet. In this situation the first call to <code>JCoCustomDestination.getRepository()</code>
on each of such a <code>JCoCustomDestination</code> instance created a memory leak in the Java heap being located in the
returned <code>JCoRepository</code> object.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for connection reset handling against R/3 release 4.6C systems</b></td></tr>
<tr><td>
When communicating with an R/3 release 4.6C system which is running with a 4.6D kernel, the reset of pooled connections was
not working as expected. Instead of simply resetting the context in the backend, the connection was closed and re-established
again. In networks with high latency this led to an undesired performance degredation. This was caused by wrongly checking the
partner release number instead of the kernel release number.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in JCoServer restart mechanism when processing update events</b></td></tr>
<tr><td>
When a server had to be restarted due to a change in the configuration being signaled by an update event, the server did not
come up, but was stopped instead. In particular, simply adjusting the trace flag led to this situation. This was caused
by the fact, that the new server instance was already started, before the old one had been shutdown completely.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for usage of the destination and server data connection property 'gwserv'</b></td></tr>
<tr><td>
If specifying a gateway service with the destination data connection property 'jco.client.gwserv' or with the server data
connection property 'jco.server.gwserv', all property string values of format sapgw##s (with # being a placeholder for a
digit) were not accepted and an exception was thrown or an error message was logged saying that the gateway service
parameter needs to be of a different format. Contrary to this error message, gateway service parameters of format sapgw##s
are valid and may be specified alternatively to parameter values of format sapgw## or #### for directly specifying the
TCP port number.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for JCoCustomDestination instances not getting invalidated</b></td></tr>
<tr><td>
A <code>JCoCustomDestination</code> instance was never invalidated and remained usable, even if the destination configuration,
which it is based on, was changed or deleted. Now a <code>JCoException</code> with error group
<code>JCoException.JCO_ERROR_DESTINATION_DATA_INVALID</code> will correctly be thrown, if a <code>JCoCustomDestination</code>
instance will be used in such a situation.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for SSO-Tickets and X.509-Certificates not being used with JCoCustomDestination</b></td></tr>
<tr><td>
New SSO-Tickets or X.509-Certificates that are set for a <code>JCoCustomDestination</code> instance were not used, in case
that there was already another SSO-Ticket or X.509-Certificate previously being used for this destination. The previously
set SSO-Ticket or X.509-Certificate was cached and still used instead of the new one. This led to a <code>JCoException</code>
with error group <code>JCoException.JCO_ERROR_LOGON_FAILURE</code> being thrown, if the SSO-Ticket or X.509-Certificate
has been expired in the meantime.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for wrong repository destination being used with JCoCustomDestination</b></td></tr>
<tr><td>
After setting a repository destination with method <code>JCoCustomDestination.setRepositoryDestination(JCoDestination)</code>,
the <code>JCoCustomDestination</code> instance used the passed destination's client connections instead of the desired
repository connections. Depending on the destination configuration this might have led to a wrong repository being
returned on a subsequent call to <code>JCoCustomDestination.getRepository()</code> and/or wrong targeted connections
and logon parameters being used for future meta data queries of the returned <code>JCoRepository</code> instance.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Improved JCoCustomRepository destination setting</b></td></tr>
<tr><td>
The setting of a destination for a <code>JCoCustomRepository</code> instance has been improved. Now it is possible to change
the destination for remote meta data queries with method <code>JCoCustomRepository.setDestination(JCoDestination)</code>.
Before this improvement, it was only allowed to set a destination once and subsequent calls to
<code>JCoCustomRepository.setDestination(JCoDestination)</code> led to a <code>JCoRuntimeException</code> with error group
<code>JCoException.JCO_ERROR_ILLEGAL_STATE</code> being thrown.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix at creation of JCoDestinationMonitor objects</b></td></tr>
<tr><td>
The method <code>JCoDestination.getMonitor()</code> threw a <code>JCoRuntimeException</code> with error group
<code>JCoException.JCO_ERROR_RESOURCE</code> saying that the destination would not be initialized or would have been already
removed, although this was not true and the <code>JCoDestination</code> instance was actually valid. This error situation
only occurred if the <code>JCoDestination</code> instance's <code>getMonitor()</code> method was called for the first time
and there was no connection pool available for this destination at that time.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in JCoDestinationMonitor returning wrong data</b></td></tr>
<tr><td>
<code>JCoDestinationMonitor</code> instances returned wrong data after the connection pool being associated to the monitored
<code>JCoDestination</code> instance was temporarily removed due to inactivity on this destination. In such an error
situation the <code>JCoDestinationMonitor</code> instance always reported that there would not be any open connection and
consequently the number of pooled and used connections would both be <code>0</code>. But that potentially did not reflect
the real situation where several new connections for the monitored destination meanwhile might have been opened again.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>New API</b></td></tr>
<tr><td>
The following new API has been added and is available for general use:
<code>
<ul>
    <li>JCoDestinationMonitor.isValid()
</ul>
</code>
See the API Documentation for details.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for creation of JCoRepository objects</b></td></tr>
<tr><td>
The method <code>JCoDestination.getRepository()</code> threw a <code>JCoRuntimeException</code> with error group
<code>JCoException.JCO_ERROR_CONFIGURATION</code> saying that the configuration for this destination would be invalid
in case there was a repository user defined, but no standard user, user alias or logon ticket were configured. Contrary
to this error message, a destination configuration containing only a repository user is sufficient at least for the
creation of and usage by a <code>JCoRepository</code> instance.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Improved default behavior with connection pooling</b></td></tr>
<tr><td>
The default behavior regarding the connection pooling has been improved. If the <code>DestinationDataProvider</code>
does not specify the property <code>jco.destination.pool_capacity</code> for a certain destination, the default value
<code>1</code> is used for this property now instead of <code>0</code>. This means that connection pooling is enabled
by default now and thus dramatically increases the performance of typical single threaded applications who do not care
about connection pooling.
</td></tr>

<tr><td>&nbsp;</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td><FONT SIZE="+1"><B>Release notes 3.0.7</B></FONT></td></tr>
<tr><td>&nbsp;</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Support for scope types in the default implementation of the session reference provider</b></td></tr>
<tr><td>
The default implementation of the SessionReferenceProvider was re-implemented as DefaultSessionReferenceProvider and is now exposed in
com.sap.conn.jco.ext package and supports scopeTypes by default. If an application/infrastructure that uses the default implementation wants
to disable scopeType support again it has to register new DefaultSessionReferenceProvider(false) via the Environment class.
<br/>Find more details in the JavaDoc.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Deprecations</b></td></tr>
<tr><td>
Some methods in the <code>JCoDestinationManager</code>, the <code>JCoServerFactory</code>, and <code>JCo</code>
have been deprecated. Adjust your coding accordingly so that you don't run into trouble, if those methods are
removed from the public API in future versions of JCo.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>New APIs</b></td></tr>
<tr><td>
The following new APIs have been added and are available for general use:
<code>
<ul>
    <li>JCoMetaData.setName(String)
    <li>JCoRecordMetaData.setLineType(String)
    <li>JCoRecord.write(int, Writer)
    <li>JCoRecord.write(String, Writer)
    <li>JCoDestination.isValid()
    <li>JCoServer.isValid()
</ul>
</code>
See the API Documentation for details.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in SimpleSessionReferenceProvider</b></td></tr>
<tr><td>
Under high load, an exception could occur signalling a concurrent modification within an internal HashMap. The exception
callstack could look like as follows:
<pre>java.util.ConcurrentModificationException
at java.util.HashMap$AbstractMapIterator.checkConcurrentMod()
at java.util.HashMap$AbstractMapIterator.makeNext()
at java.util.HashMap$KeyIterator.next()
at java.util.HashMap.analyzeMap()
at java.util.HashMap.rehash()
at java.util.HashMap.rehash()
at java.util.HashMap.putImpl()
at java.util.HashMap.put()
at com.sap.conn.jco.rt.SimpleSessionRefProvider.jcoServerSessionPassivated()
at com.sap.conn.jco.rt.DefaultServerWorker.callFinishedInternal()</pre>
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in JCoRepository with regard to destination handling</b></td></tr>
<tr><td>
A repository is shared between several destinations that all establish own connections to the
ABAP system. The destination that is actually used for the lookup causes a <code>JCoException</code> with group
<code>JCoException.JCO_ERROR_LOGON_FAILURE</code>. This exception is thrown due to an incorrect configured repository
user/repository password combination or because the user is locked (e.g. due to running out of the validity period).
Hence, repository queries failed, as repeatedly the &quot;bad&quot; destination is used instead of switching
to the next valid one, which could be used successfully for the query, even though such a mechanism exists in the repository.
Moreover, it could happen that a working backend user used for metadata lookup is locked after several metadata query tries,
and you will get the message "Password logon no longer possible" when trying to logon with this user.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Enhancement: special ThreadGroup for Threads created by JCo</b></td></tr>
<tr><td>
When JCo is creating Threads internally (e.g. in a <code>JCoServer</code> without a special <code>JCoServerRunnable</code>
implementation or for the Timeoutchecker thread), they are now assigned to a dedicated ThreadGroup belonging to JCo. Thus,
the threads are no longer belonging to random thread groups of the runtime environment, depending on the creation point in
time of the concrete thread.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Enhancement: DataProviderException</b></td></tr>
<tr><td>
Now, an implementation of DestinationDataProvider and ServerDataProvider may throw a DataProviderException to
report an exceptional situation, it encountered while a certain configuration has been requested.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in JCoServer setup</b></td></tr>
<tr><td>
When using SNC for a <code>JCoServer</code> and using <code>9</code> as value for
<code>jco.server.snc_qop</code>, JCo complained wrongly about an invalid value.
This was due to a wrong range usage, when checking the properties: JCo used [0..8] instead of [1..9].
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in JCoServer transaction and unit processing setup</b></td></tr>
<tr><td>
When there is no <code>JCoServerTIDHandler</code> or no <code>JCoServerUnitIDHandler</code> set for a <code>JCoServer</code>,
and a tRFC/qRFC or bgRFC unit is received by a server, a <code>NullPointerException</code> without descriptive
message is thrown. If such a handler is missing and a corresponding request shall be processed, JCo now throws a
a <code>JCoRuntimeException</code> with group <code>JCoException.JCO_ERROR_ILLEGAL_STATE</code> that provides a clarifying message.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in JCoServer called by 3.1I ABAP Server</b></td></tr>
<tr><td>
Since JCo 3.0.5, if a 3.1I ABAP System made a request to a JCoServer, it caused an exception with a
message similar to
<tt>RFC_ERROR_SYSTEM_FAILURE: You cannot adjust the state of a ServerConnection with this method.</tt>
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for deployment errors</b></td></tr>
<tr><td>
Sometimes a JCo standalone was deployed accidentally into a NetWeaver AS Java. This could lead to strange
error situations that were randomly occuring. Hence, JCo standalone is now denying to be loaded within
a NetWeaver AS Java. If JCo should be used within that environment, the embedded JCo variant should be
used (can be referred to as tc/bl/jco/api, an application only needs to set this reference in its
deployment descriptor).
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for JCoSessionReferenceProvider server event jcoServerSessionFinished()</b></td></tr>
<tr><td>
In a stateless server context, the event method <code>jcoServerSessionFinished()</code> received always null as session ID and not
the expected session ID that was originally provided by the <code>JCoSessionReference</code> returned by <code>jcoServerSessionStarted()</code>.
</td></tr>

<tr><td>&nbsp;</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td><FONT SIZE="+1"><B>Release notes 3.0.6</B></FONT></td></tr>
<tr><td>&nbsp;</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Connect failure on load balanced logon under heavy load</b></td></tr>
<tr><td>
Caused by a race condition, the JCo runtime could use wrong service if connection was being
established via the message server, that means using load balanced logon. In such cases,
JCo throws an exception with the following error text
<pre>
    LOCATION    SAP-Gateway on host <host> / sapgwXX
    ERROR       partner '<host>:sapgwYY' not reached
</pre>
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Data element names missing in metadata since JCo 3.0.5</b></td></tr>
<tr><td>
If in a structure, table or function module a scalar type (e.g. CHAR, NUMC, etc) is refering to a data element,
the name of that data element is not returned in getRecordTypeName() in JCo 3.0.5, though this worked fine in
JCo 3.0.0 to 3.0.4.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in JCoRepository</b></td></tr>
<tr><td>
If a vector of a domain was looked up directly, it did not contain the linetype, hence was not
handled like a table type properly.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for JCoCustomDestination</b></td></tr>
<tr><td>
A <code>JCoDestination</code> is associated with a scopeType via <code>JCoDestinationManager.getDestination(destName, scopeType)</code>.
When now creating a <code>JCoCustomDestination</code> from the retrieved destination, the scopeType
information is ignored, when executing a function module.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Enhancement for tracing</b></td></tr>
<tr><td>
When tracing at high trace levels and large data volumes, the memory footprint of JCo was
increasing stronger than necessary leading to <code>OutOfMemoryErrors</code> too early. Now, the
memory consumption has been reduced and such errors should come up only with even higher data
volumes.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Enhancement for session timout checking</b></td></tr>
<tr><td>
It was impossible to adjust JCo session timeout checking independently from the timeout interval.
This was changed by introducing <code>jco.session_timeout.check_interval</code> that allows specifying a value
in minutes and defaults to 5.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Roundtrip reduction for repository</b></td></tr>
<tr><td>
When JCo is looking up metadata in a backend for a certain function module, it calls several function modules
providing metadata for the function and the involved structures. In slow networks, e.g. a VPN connection
crossing longer distances, this can lead to bad performance in case of design time scenarios, where the
repository cache is typically not filled and many roundtrips to the backend are needed.
SAP note <a href="https://service.sap.com/sap/support/notes/1456826">1456826</a> introduces
<code>RFC_METADATA_GET</code>, with which the number of roundtrips per function is reduced to 1.
JCo now uses this function module, if it's available in the backend and if the JCo property
<code>jco.use_repository_roundtrip_optimization</code> is set to 1. Please note, that you need
to adjust authorization profiles for your metadata user in that case.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in XRfcParser</b></td></tr>
<tr><td>
When table type FOO has a table type BAR as line type and one of the rows of FOO contains simply an
empty table BAR, then an expeption occured that looks similar to:
<i>JCO_ERROR_XML_PARSER: Parameter PARAM_FOO: After a value an end tag must follow. That did not
happen in "em><item><BAR_COL"</i>.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in initialization of RFC parameter defaults</b></td></tr>
<tr><td>
RFC function module parameters might not have been initialized correctly when an ABAP system field
(e.g. <code>SY-DATLO</code> or <code>SY-TIMLO</code>) was defined as its default value. This also
might have led to some <code>ConversionException</code> being thrown when trying to read these
values with the <code>JCoParameterList.getValue()</code> or the various <code>JCoParameterList.get&lt;type&gt;()</code>
methods.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in server registration</b></td></tr>
<tr><td>
If a gateway is protected with a reginfo file, a <code>JCoServer</code> is not allowed
to register itself from a certain host and/or a certain program ID with that gateway. Unfortunately, the
<code>JCoServer</code> did not recognize such a registration failure as an unrecoverable configuration error,
and hence tried to re-register again immediately. This was certainly failing again, which was leading to
rapidly growing dev_jco_rfc.trc files.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix when degistering DestinationDataProvider</b></td></tr>
<tr><td>
When a <code>DestinationDataProvider</code> is deregistered from JCo, the connections established by
destinations created from this provider should be closed. However, this did not work for repository
connections. If afterwards the JCo application is terminated, the ABAP system wrote an
entry containing "SAP-RC=223" into the syslog.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfixes in server configuration processing</b></td></tr>
<tr><td>
When processing changes in server configurations signalled by the <code>ServerDataProvider</code>, not all changes were recognized by the <code>JCoServer</code>.
Even if a change was recognized, and a running server was updated, it was no longer running after that update, but
was simply stopped. In case of restarts, the setting for the maximum restart delay time was ignored.
</td></tr>

<tr BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Documentation improved</b></td></tr>
<tr><td>
Documentation was added and enhanced at different locations, in particular in the cases mentioned below:
<ul>
    <li>Existing JCo properties are now documented
</ul>
</td></tr>

<tr><td>&nbsp;</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td><FONT SIZE="+1"><B>Release notes 3.0.5</B></FONT></td></tr>
<tr><td>&nbsp;</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>New API and constant</b></td></tr>
<tr><td>
The following new API and constant have been added and are available for general use:
<code>
<ul>
    <li>JCoCustomDestination.setUseSapGui()
    <li>JCoCustomRepository.QueryMode.DISABLE_REPOSITORY_POOL
</ul>
</code>
See the API Documentation for details.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>NullPointerException in Delta Management on ABAP callbacks</b></td></tr>
<tr><td>
If an ABAP function module executes a function via destination <tt>BACK</tt>, a <code>NullPointerException</code> could be thrown
by delta management in JCo. The exception is raised only, if the function module invoked in ABAP has some table parameters.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Support of multiple repositories for a single JCoServer</b></td></tr>
<tr><td>
It is now possible to specify more than one repository for <code>JCoServer</code> and thus be able to
handle requests from various ABAP systems, even if requests base on incompatible function module definitions.
In order to define multiple repositories, JCo introduces a new configuration property: <code>jco.server.repository_map</code>.
Examples how to use it are available in the API documentation of <code>ServerDataProvider</code>.

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Support of dynamic worker thread allocation for JCoServer</b></td></tr>
<tr><td>
It is now possible to specify the minimum and maxmimum number of worker threads that shall be used for a JCo Server
via the new server properties jco.server.worker_thread_min_count and jco.server.worker_thread_count.
Mor edetails are available in the API documentation of <code>ServerDataProvider</code>.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Invalid characters accepted for BCD</b></td></tr>
<tr><td>
When setting a value for a field that is containing a BCD value, and that value contains an invalid character,
e.g. an 'a', this value is accepted without error instead of throwing an exception.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Support for cancelling function invocations on session end</b></td></tr>
<tr><td>
When a function module invocation is lasting very long, and as a consequence the session, in which that call was executed, has
been finished in the meantime, JCo now requests on the ABAP server that the function module execution shall be cancelled, in order
to free resources.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Loss of tRFC requests</b></td></tr>
<tr><td>
When executing multiple tRFCs in parallel threads, some of the tRFCs get lost without any error message.
In particular, this can lead to data loss during IDoc communication between a JCo 3.0 based program
and the ABAP backend system.
See also note <a href="https://service.sap.com/sap/support/notes/1438660">1438660</a>.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Performance improvement for stateless function module calls</b></td></tr>
<tr><td>
By default, function module invocations are done stateless within JCo 3.0. This means that the context in the ABAP backend
associated with a connection used for a function module invocation is reset after finishing the request. Unfortunately, this is
much slower for many small requests than executing stateful due to the existing reset mechanism. With a small improvement within
the JCo runtime the reset mechanism could be improved, but requires also an enhancement in the ABAP backend side. If that enhancement
is not available, the behavior will stay like before. Note <a href="https://service.sap.com/sap/support/notes/1433584">1433584</a>
describes which kernel patch level is necessary for the ABAP server.
</td></tr>


<tr><td>&nbsp;</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td><FONT SIZE="+1"><B>Release notes 3.0.4</B></FONT></td></tr>
<tr><td>&nbsp;</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>JCoException with text "Incorrect size of TID encountered [null]" thrown for synchronous client call</b></td></tr>
<tr><td>
If a destination is set to stateful, a qRFC call is executed, and afterwards a synchronous call is executed for the same destination, the JCoException with the message
mentioned above is thrown though this should work fine without any problem.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Exception JCO_ERROR_CONFIGURATION on JCoCustomDestination</b></td></tr>
<tr><td>
JCoException with the key <tt>JCO_ERROR_CONFIGURATION</tt> is thrown on a JCoCustomDestination, if the original JCoDestination it was created from
does not contain any user authentication parameters.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Unnecessary refresh on deregistration of DestinationDataProvider</b></td></tr>
<tr><td>
If a DestinationDataProvider is changed or removed, the JCo runtime refreshes the cached destinations. Due to a bug in the
refresh operation, the instance of the DestinationDataProvider was used that was just in being deregistered, and not the new one as it should be.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>z/OS: ERROR hostname 'abcd' unknown </b></td></tr>
<tr><td>
Even though the technical connection to a certain host was working fine outside JCo, establishing a connection
with JCo to an SAP system failed. This was caused by some EBCDIC/ASCII translation issues in a very low level
API. See also note <a href="https://service.sap.com/sap/support/notes/1406061">1406061</a>.

</td></tr>


<tr><td>&nbsp;</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td><FONT SIZE="+1"><B>Release notes 3.0.3</B></FONT></td></tr>
<tr><td>&nbsp;</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Support for dealing with bgRFC units</b></td></tr>
<tr><td>
It is now possible to interact with backends supporting the successor of tRFC and qRFC
completely in native bgRFC mode, both for client and server aplications. Certainly, the backend release
has to support bgRFC as well. For details check out the API documentation of the interfaces and enums below:
<code>
<ul>
    <li>JCoFunctionUnit
    <li>JCoRequestUnit
    <li>JCoUnitIdentifier
    <li>JCoBackgroundUnitAttributes
    <li>JCoFunctionUnitState
    <li>JCoServerUnitIDHandler
</ul>
</code>
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Support for ABAP class exceptions</b></td></tr>
<tr><td>
Starting with ABAP application server release 7.11 it is possible to use function modules throwing an
abap class exception between two ABAP systems. With 7.20 the support was extended to connectors as well,
including JCo 3.0. Hence, more context of the application in the ABAP system can be transferred in
such an exception object, which makes it easier to find causes of undesired behavior of the application.
For details check out the API documentation of the classes and interfaces below:
<code>
<ul>
    <li>AbapClassException
    <li>JCoRemoteContext
    <li>JCoAbapObject
    <li>JCoClassMetaData
    <li>JCoFunction
</ul>
</code>
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Changing parameters are not updated</b></td></tr>
<tr><td>
When a function module had a changing parameter, and the application did not set any value to it, before
invoking function module in the backend, the updates to it in the backend were not received by the Java
application.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>StackOverflowError in MetaDataStorage</b></td></tr>
<tr><td>
Under certain circumstances it could occur when some metadata object is stored in a
repository's data store. The call stack of the error included the following sequence very often:
<pre>
at com.sap.conn.jco.rt.MetaDataStorage.updateParents()
at com.sap.conn.jco.rt.MetaDataStorage.saveRecordMetaData()
at com.sap.conn.jco.rt.MetaDataStorage.storeNestedMetaData()
at com.sap.conn.jco.rt.MetaDataStorage.saveFunctionTemplate()
at com.sap.conn.jco.rt.MetaDataStorage.updateParents()
at com.sap.conn.jco.rt.MetaDataStorage.saveRecordMetaData()
at com.sap.conn.jco.rt.MetaDataStorage.storeNestedMetaData()
at com.sap.conn.jco.rt.MetaDataStorage.saveFunctionTemplate()
at com.sap.conn.jco.rt.MetaDataStorage.updateParents()
at com.sap.conn.jco.rt.MetaDataStorage.saveRecordMetaData()
at com.sap.conn.jco.rt.MetaDataStorage.storeNestedMetaData()</pre>
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>JCo cuts off the last field of a structure or table row</b></td></tr>
<tr><td>
See also note <a href="https://service.sap.com/sap/support/notes/1358698">1358698</a>.
If a table or strufture definition was extended compatibly between two releases by simply extending the last field, e.g.
by extending a CHAR 5 field to CHAR 10, and JCo was only aware of the shorter version of the metadata, but the longer one
was sent to JCo, the value of that field was simply not stored, and the field remained initial. In particular, this occurred
as well, if there was only a single field in the structure or table row.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Exception text was not sent to caller</b></td></tr>
<tr><td>
When an implementation of a <code>JCoServerTIDHandler</code> threw an exception within checkTID, the text was
not sent to the caller.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>NullPointerException in JCoServer</b></td></tr>
<tr><td>
When a <code>JCoServer</code> was started twice, because of some minor changes, and was not stopped properly before,
and the <code>ServerDataProvider</code> did not support events, this could lead to a NullPointerException, when a
new request for this server was coming in.
</td></tr>

<tr><td>&nbsp;</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td><FONT SIZE="+1"><B>Release notes 3.0.2</B></FONT></td></tr>
<tr><td>&nbsp;</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>New APIs</b></td></tr>
<tr><td>
The following new APIs have been added and are available for general use:
<code>
<ul>
    <li>JCoCustomDestination.setTrace()
    <li>JCoCustomDestination.setCodepage()
    <li>JCoAttributes.getOwnBytesPerChar()
    <li>JCoAttributes.getPartnerBytesPerChar()
    <li>Environment.isDestinationDataProviderRegistered()
    <li>Environment.isServerDataProviderRegistered()
    <li>Environment.isSessionReferenceProviderRegistered()
    <li>Environment.isClientPassportManagerRegistered()
    <li>Environment.isServerPassportManagerRegistered()
</ul>
</code>
See the API Documentation for details.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for hanging JCoServer if connections were set to stateful</b></td></tr>
<tr><td>
See also note <a href="https://service.sap.com/sap/support/notes/1298438">1298438</a>.
When setting its connections to stateful, a <code>JCoServer</code> could hang completely when the gateway on which the server has been registered is
sending a ping to the server connection because the ABAP client has not been sending requests for a while. The JCoServer connection then
ends up in a call stack for server threads in a thread dump that looks similar to the following one:
<pre>
"sap.rfc.Listener SAPBC 10.20.3.20" cpu=136953.28 [reset 136953.28] ms allocated=30367383456 B (28.28 GB)
   [reset 30367383456 B (28.28 GB)] prio=6 tid=0x0000000015328b50 nid=0x1960 runnable
   [0x000000001922f000..0x000000001922f7d0]
   java.lang.Thread.State: RUNNABLE
    at com.sap.conn.rfc.driver.CpicDriver.nativeCpic_coxread([BI[B[I)I(Native Method)
    at com.sap.conn.rfc.driver.CpicDriver.cpic_coxread(I[B[I)I(CpicDriver.java:692)
    at com.sap.conn.rfc.driver.RfcTypeRegisterCpic.listen([BI[II)I(RfcTypeRegisterCpic.java:70)
    - locked <0x000000018b411e68> (a com.sap.conn.rfc.driver.RfcTypeRegisterCpic)
    at com.sap.conn.rfc.engine.RfcIoOpenCntl.ab_rfclisten(I)I(RfcIoOpenCntl.java:1293)
    at com.sap.conn.rfc.engine.RfcIoOpenCntl.RfcListen(I)I(RfcIoOpenCntl.java:2194)
    at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.listen(LServerWorker;)V(MiddlewareJavaRfc.java:2060)
    at com.sap.conn.jco.rt.DefaultServerWorker.dispatch()V(DefaultServerWorker.java:259)
    at com.sap.conn.jco.rt.DefaultServerWorker.loop()V(DefaultServerWorker.java:321)
    at com.sap.conn.jco.rt.DefaultServerWorker.run()V(DefaultServerWorker.java:220)
    at com.wm.util.TimeWrappingProvider$TimeMesuredTask.run()V(TimeWrappingProvider.java:40)
    at com.wm.pkg.sap.rfc.ListenerThread.run()V(ListenerThread.java:70)
    - locked <0x000000017757a778> (a java.lang.Thread for sap.rfc.Listener BCSAPPRD 172.27.1.23)
</pre>
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in treatment of one-digit BCD value</b></td></tr>
<tr><td>
BCD fields were filled incorrectly if a one-digit value was set (e.g. 4 or 7). The resulting value was always 0 (or 0.0 - with n 0 after the dot if the number of decimals is n in the metadata definition).
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for exception group in case of wrong credentials</b></td></tr>
<tr><td>
Error group <code>JCO_ERROR_CANCELLED</code> was used instead of <code>JCO_ERROR_LOGON_FAILURE</code>, moreover the error message was misleading.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfixes in session context handling</b></td></tr>
<tr><td>
<ul>
    <li>It was possible that the context which timed out was not removed from the list of existing contexts by the session
        timeout checker. This could create unnecessary checks for sessions that have already been cleaned up.
    <li>Contexts that have been initiated by a stateful JCo server were not removed immediately after the connection
        had been closed by the ABAP client.
</ul>
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for clear-text password in trace</b></td></tr>
<tr><td>

The trace file of could contain a trace entry, in which you find the string
'jco.destination.repository.passwd=' followed by the password for the
repository user, i.e. the user with which metadata information is looked
up in the SAP system.

See also security note <a href="https://service.sap.com/sap/support/notes/1312880">1312880</a>

</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for stateful JCoServer connections</b></td></tr>
<tr><td>
Stateful server connections could not be set to stateless again.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for session events triggered by JCoServer connections</b></td></tr>
<tr><td>
The events for sessions started by a <code>JCoServer</code> could be triggered more often than necessary. In particular, this was
true for the <code>jcoServerSessionStarted()</code> event, for which then there did not exist a corresponding <code>jcoServerSessionFinished()</code>
event. As a consequence too many idling sessions were created in the runtime environment.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for JCoServerMonitor information</b></td></tr>
<tr><td>
Under very high load both <code>getUsedServerThreadCount()</code> and <code>getMaximumUsedServerThreadCount()</code> were increasing above
the configured maximum until the load was lower again and then remained at the wrong high level.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in numeric handling of signed or empty field values</b></td></tr>
<tr><td>
    A <code>ConversionException</code> was thrown when trying to get an empty or signed value
    from a field of type <code>CHAR</code> as a converted numeric value. The following <code>JCoRecord</code>
    methods were affected: <code>getInt()</code>, <code>getShort()</code>, <code>getLong()</code>,
    <code>getBigInteger()</code>, <code>getDouble()</code>, <code>getFloat()</code> and <code>getBigDecimal()</code>.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in repository for nested vector types</b></td></tr>
<tr><td>
    Table types that referred to a table type as line type which itself refers again to a table type as line type and
    table types that referred to a table type as line type which referse to a domain as line type were not correctly
    stored in the repository, when being looked up from an ABAP system. As a consequence function modules that had parameters
    of such a type could not be processed correctly.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for java.lang.UnsatisfiedLinkError</b></td></tr>
<tr><td>
A <code>java.lang.UnsatisfiedLinkError</code> occurred with the message <code>com.sap.i18n.cp.ConverterJNI.ConvertCToXArrR([B[CII[BII[I)I</code>, when a blended
codepage such as 6100 is used.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for starting SAP GUI on Unix and MacOS</td></tr>
<tr><td>
If the path to the SAP GUI contained blanks, starting the Java GUI failed. On MacOS, in addition some startup parameters
needed to be adopted.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for tables in changing parameter lists</b></td></tr>
<tr><td>
If a table was part of the changing parameter list, and was not containing any row when executing the function module, then
the table was always returned empty.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Enhancement for destination and server configuration management</b></td></tr>
<tr><td>
If a configuration was updated, and someone uses a cached instance of a JCoServer or JCoDestination, an exception will be thrown to signal
that this instance is outdated.
</td></tr>

<tr><td>&nbsp;</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td><FONT SIZE="+1"><B>Release notes 3.0.1</B></FONT></td></tr>
<tr><td>&nbsp;</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Improved documentation</b></td></tr>
<tr><td>
An example for a CustomDestinationProvider has been added.
<p>API Documentation has been extended and improved.</p>
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>New APIs</b></td></tr>
<tr><td>
The following new APIs have been added and are available for general use:
<code>
<ul>
    <li>JCo.getTraceLevel()
    <li>JCo.getTracePath()
    <li>JCoConnectionData.getSystemID()
</ul>
</code>
See the API Documentation for details.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Support for SAPGUI</b></td></tr>
<tr><td>
JCo is now able to start a SAP GUI on the local machine and associate it with a newly opened RFC connection. The backend prerequisites for this new feature are listed in
note <a href="https://service.sap.com/sap/support/notes/1258724">1258724</a>. Starting
the SAP GUI can be controlled by the additional destination parameter <code>jco.client.use_sapgui</code>.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in dispatcher worker thread</b></td></tr>
<tr><td>
The dispatcher worker thread might have been finished after errors occurring under heavy load. The thread dump
does not contain a thread called <code>JCoDispatcherWorkerThread</code> in this case.
<br>
The dispatcher worker thread might be started more than once due to insufficient synchronization. The thread dump
contains more than one thread called <code>JCoDispatcherWorkerThread</code> in this case.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for functions containing more than 127 non-scalar parameters</b></td></tr>
<tr><td>
Functions with more than 127 non-scalar parameters caused an <code>ArrayIndexOfBoundsException</code>. The fix required a change for the
serial version UID of many data containers and metadata instances so that serialized instances of these classes can no longer be exchanged
with previous releases.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for ArrayIndexOutOfBoundsException on receive</b></td></tr>
<tr><td>
<code>ArrayIndexOutOfBoundsExceptions</code> might be thrown while receiving data (output parameters in client scenario or
input parameters in server scenario). The exception is thrown if the ABAP side has extended the data strcutures used
by the current function module compared to JCo's own metadata definition.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for JCO_ERROR_DSR_PASSPORT_NOT_RECEIVED</b></td></tr>
<tr><td>
A <code>JCoException</code> with the key <code>JCO_ERROR_DSR_PASSPORT_NOT_RECEIVED</code> was thrown in a JCo server on second
and subsequent stateful requests.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in treatment of default BCD value</b></td></tr>
<tr><td>
BCD fields were filled incorrectly if the default values was set. On the ABAP side the incorrect content of the BCD
field caused short dumps (ABAP runtime error BCD_BADDATA).
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix in firing of server events</b></td></tr>
<tr><td>
The event <code>ALIVE</code> was not fired by the JCo runtime, if the ABAP system/gateway hase gone online when
the server was in the state <code>DEAD</code>. That might cause that the server application remained in the
the waiting state.
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for native crash during stateful server communication</b></td></tr>
<tr><td>
A native crash occurred on stateful requests from ABAP to Java
<ul>
    <li>on the second or any subsequent request during a stateful server communication
    <li>and if the request data volume was greater than 16000 bytes in the internal RFC representation
</ul>
</td></tr>

<tr  BGCOLOR="#CCCCFF" CLASS="TableHeadingColor"><td><b>Bugfix for server connection leak</b></td></tr>
<tr><td>
The JCo server did not release the internal connection handle properly, if the gateway was protected
with an ACL and the connection was declined. After a while all internal handles were used and either an <code>ArrayIndexOutOfBoundsException: 10000</code> was thrown and
logged to dev_jco_rfc.trc each time a new connection was required. <br>
This is the same issue like described in note <a href="https://service.sap.com/sap/support/notes/1252962">1252962</a>

</td></tr>

<TR>
<TD>
<hr>
</TD>
</TR>
<TR>
<TD>
<i>Copyright &#169; 2008-2012 SAP AG. All Rights Reserved.</i>
</TD>
</TR>
</BODY>
</HTML>
